Outils de workflow

Airflow, édité par Apache. Il a été testé par des collègues.

Il nécessite un executor pour lancer les workers, par exemple celery ou kubernetes.

Les workflows (qui s'appellent ici des pipelines) se définissent en python sans UI.

Mais la visualisation des workflows en cours est possible via un UI.

Un chart helm est fourni également.

Pas mal d'implémentation de job génériques sont disponibles via les plugins : envoyer un mail, faire une requête SFTP, etc.

Écosystème full python.

Conductor de Netflix, utilisé chez eux en interne.

Jamais utilisé et je n'ai pas de retours donc je me fie à leur doc.

Les workflow se définissent en JSON ou via une UI. Une nterface de debug est fournie avec le temps passé par job et un pilotage précis de chaque workflow.

Résilient et scalable.

Worker possibles en Java, NodeJS, Python ou C#.

[EDIT : projet archivé le 13/12/2023]

Outil d'orchestration assez récent, écrit en Go avec des SDK dans différentes technos (Python, Go, TS, PHP, Java).

Il y a le choix entre de l'auto-hébergé ou un service cloud pour le serveur d'exécution.

Côté fonctionnement c'est assez classique, avec un appel pour lancer le workflow, et les workers qui vont pull et exécuter une tâche quand elle est en attente, avec des option de retry, timeout, etc.

Simple à déployé et robuste, ça tourne bien en production d'après les retour que j'ai eu, même sur des workflows de longues durées (= dizaines de jours)

Director d'OVH.

Une surcouche à Celery.

Les workflows sont définis en YAML et appellent simplement des tasks celery.

Une UI de visualisation est disponible.

Il a l'air super simple et léger. Dans un écosystème Python ou on fait déjà du celery c'est très facile de l'intégrer.

Sa grande force réside dans l'ensemble de ses plugins de connexion qui permettent de s'interfacer avec un grand nombre de services déjà intégrés.
Il est possible de coder de nouvelles tâches en JS ou Python

Similaire à n8n, plus jeune, mais propose une approche différente : plutôt que de faire du drag&drop, les workflows sont définis en YAML.

L'interface de suivi est claire, on y retrouve à la fois les logs ainsi que les durées de chaque tâche et leur status.

Les workers sur-mesure peuvent être écrits en Python, R, Node.js, Julia, Ruby, Shell, ou PowerShell.

Proche de l'approche DAG d'Airflow

Zeebe, édité par Camunda. Je l'ai utilisé pour gérer les workflows des commandes pour une application e-commerce, avant qu'il ne soit remplacé par Temporal.

Zeebe lui-même est opensource mais pas les autres outils de son écosystème, dont on peut difficilement se passer en production et dont le prix des licences est prohibitif (35'000€/an pour le droit de les déployer en production en autohébergé).

C'est un assez gros bouzin qui m'a donné une mauvaise expérience en dev et les configuration par défaut en prod ne sont pas robustes (après je n'ai aucune expertise en administration Java, ça ne doit pas aider).

Retry automatique, les workers sont indépendants et peuvent être écrits en n'importe quel langage via un système de communication GRPC, il faut néanmoins penser à implémenter soit-même l'idempotence des tâches.

Les workflows se définissent par schéma BPMN, pratique pour pouvoir présenter aux équipes métier, mais d'expérience, ça restera les dev qui modifieront les schema donc le gain reste limité.

S'accompagne d'un deuxième outil, Operate (licence payante si utilisée en production), pour avoir le suivi et pouvoir interagir graphiquement avec les workflows en cours d'exécution.

Offre SaaS disponible pour tout ça, nous on a opté pour de l'auto-hébergé sur notre cluster Kubernetes, en utilisant le chart helm fourni. Le cluster zeebe ne peut pas être redimensionné (ajout ou retrait de nœud) dynamiquement à chaud.

Il n'est pas non plus possible de revenir en arrière dans un workflow, juste le stopper ou relancer un job en échec.

Le petit dernier et pourtant l'un des plus vieux : la solution d'Uber nommée Cadence vient de passer en V1.

En préparation depuis 6 ans, Temporal serait à l'origine un fork de celle-ci.

Il est fait en go. Les workflow sont définis par du code (Java ou Go officiellement, Python ou Ruby via des portages communautaires).

Il possède une UI pour l'observabilité.

On peut choisir sa solution de persistance de données, notamment PostgreSQL est supporté.